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Systeme modulaire pour la gestion d'appels de services, 
notamment de telecommunication 

La presente invention concerne un systeme pour la gestion d'appels de 
services, notamment de services de telecommunication. Ces services de 
telecommunication peuvent par exemple etre I'etablissement d'une 
communication avec un abonne soit par un reseau classique de 
telecommunication, soit par Internet (VoIP pour Voice over IP, en anglais), ou 
bien I'etablissement d'une teleconference ou videoconference, d'un reseau 
prive (VPN pour Virtual Private Network, en anglais), d'un appel avec 
tarification speciale (numero 800 par exemple), etc. 

[.'invention trouve, par exemple, une application dans les architectures 
de type reseau intelligent. Dans ce genre d'architecture, ou dans toute autre 
architecture de telecommunication evoluee, il est connu de mettre en oeuvre 
des mecanismes de contrdle d'acces aux services, tels des filtres bases sur 
Pidentificateur de ('appelant, sur la zone geographique de ('appelant, ou sur 
I'horaire de I'appeL On peut aussi mettre en oeuvre des renvois d'appels, qui 
peuvent etre soit inconditionnels, soit conditionnes par Pidentificateur de 
I'appelant, sa zone geographique, I'horaire de son appel etc. Bien 
evidemment, la liste des controles d'acces possibles ne peut pas etre donnee 
de fagon exhaustive. 

Chaque service peut utiliser un de ces controles d'acces ou bien 
plusieurs de ceux-ci. Une description de chaque sen/ice, en ce qui concerne 
les controles d'acces qu'il desire utiliser, est done necessaire. 

Plus particulierement, dans le cadre de la simple telephonie, il convient 
d'effectuer une description de chaque abonne au reseau de 
telecommunication, pour ce qui est des controles d'acces qu'il souhaite mettre 
en oeuvre. 
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Or le besoin existe de pouvoir ajouter de nouveaux controles d'acces, et 
modifier ceux existants notamment pour les ameliorer. 

Par exemple, un abonne peut, a un moment donne, decider d'ajouter un 
mecanisme de filtrage sur Tidentificateur de I'appelant d cause d'appels 
5 nuisibles et repetitifs provenant d'un appelant particulier. 

Actuellement, ces controles d'acces sont generalement codes au sein 
d'un systeme de gestion des appels de services sous une forme statique. Plus 
precisement, le fournisseur du systeme livre une plate-forme complete et non 
10 evolutive. Ainsi, ('implantation d'un nouveau controle d'acces, s'il n'etait pas 
prevu au depart, engendre un fort cout puisqu'il oblige a re-developper une 
partie du systeme. 

Par ailleurs, les fournisseurs de modules logiciels rnettant en oeuvre ces 
controles d'acces et les fournisseurs de I'architecture devant mettre en oeuvre 
15 ces modules, ne sont pas necessairement les memes, de sorte qu'un surcout 
important d'interoperabilite est engendre. 

Une deuxieme solution de I'etat de la technique consiste a decrire le 
comportement du systeme pour chaque abonne (ou plus generalement, pour 

20 chaque service) en un langage de description, comrne, par exemple, le 
langage CPL (pour Call Processing Language). Dans la description de chaque 
abonne, on peut faire appel a chacun des controles d'acces existants, et 
ajouter un nouveau controle d'acces consiste a modifier la description des 
abonnes concernes pour faire appel a ce nouveau controle d'acces. 

25 Toutefois, cette solution n'est pas non plus satisfaisante, car, par nature, 

un langage de description est limite en possibilites et ne permet pas de 
prendre en compte les services les plus avances. 

Par exemple, un langage comme CPL ne permet pas de faire appel 
directement a une base de donnees, ni d'appeler des modules logiciels 

30 developpes dans un autre langage, c'est-a-dire des composants logiciels 
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pouvant s'executer de fagon autonome (par exemple, du code compile ou 
interprets par une machine virtuelte Java...). 

Le but de I'invention est done de resoudre ces problemes en proposant 
5 un systeme performant et evolutif. Elle a pour objet un systeme pour la gestion 
d'appels de sen/ices comportant des modules de controles d'acces mettant en 
oeuvre des mecanismes de controle d'acces aux services, qui se distingue en 
ce qu'il comporte en outre des modules rnaTtres, chacun etant associe a un 
service et a un ensemble de modules de controle d'acces et comportant : 
10 • des moyens pour recevoir les appels de service, 

• des moyens pour transmettre des informations relatives a chacun des 
appels a I'ensemble de modules de controle d'acces, 

• des moyens pour decider de I'acceptation des appels en fonction de 
donnees regues de I'ensemble de modules de controle d'acces. 

15 

Selon une mise en oeuvre particulierement avantageuse de I'invention, 
chacun des modules maTtres est de surcroTt associe a un ensemble de 
modules de traitement d'appel, et possede en outre des moyens pour 
transmettre des secondes informations relatives a chacun des appels, a cet 
20 ensemble de modules de traitement d'appel, si I'appel a ete accepte. 

Le systeme selon I'invention est aussi susceptible de s'appliquer a toute 
architecture, en dehors du monde des telecommunications ou il est possible 
de distinguer I'acces au service du traitement proprement dit. 

25 II peut par exemple s'agir de la gestion de tout systeme complexe 

(chaine de production, centrale nucleaire...). Dans le domaine des 
telecommunications, I'invention peut aussi s'appliquer aux reseaux de gestion 
des telecommunications (TMN pour Telecommunication Management 
Network, en anglais) ainsi que definis par les normes M.3000 et suivantes de 

30 I'lTU-T (International Telecommunication Union, Telecommunication part). 
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[.'invention a aussi pour objet un procede pour la gestion d'appels a des 
services qui se caracterise en ce qu'il comporte les etapes ordonnees 
5 suivantes : 

• reception d'un appel par un module maTtre, 

• transmission par ledit module maTtre, d'informations relatives d 
I'appel a un ensemble de modules de controle d'acces, 

• etablissement de decisions par les modules de controle d'acces, d 
10 partir des informations relatives d I'appel, 

• transmission d'au moins une de ces decisions, depuis I'ensemble de 
modules de controle d'acces, vers le module maTtre, 

• etablissement d'une decision finale par le module maTtre, en fonction 
de cette au moins une decision. 

15 

L'invention et ses avantages apparaTtront de fagon plus claire dans la 
description qui va suivre en liaison avec les figures jointes. 

La figure 1 illustre le systeme selon l'invention, de fagon generale et 
schematique. 

20 La figure 2 represente un premier mode de realisation de ['invention. 

La figure 3 represente un second mode de realisation de ('invention. 
La figure 4 schematise une mise en oeuvre de l'invention, comportant 
des modules de traitements d'appel. 

25 La figure 1 illustre schematiquement la structure generale du systeme 

selon une mise en oeuvre de l'invention. 

Sur cette figure, un module maTtre M regoit des appels C de services 
depuis un reseau T. A la reception de chaque appel C, il transmet des 
informations I relatives d cet appel d un ensemble E de modules de controle 

30 d'acces A u A 2 ... A n . Ces modules de controles d'acces sont des entites, par 
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exemple logicielles, mettant en oeuvre chacune un mecanisme de controle 
d'acces comme evoque precedent, c'est-a-dire typiquement un renvoi d'appel 
ou un filtrage etc. 

5 Le module maTtre possede en outre des moyens pour decider de 

('acceptation de I'appel en fonction de donnees D regues des modules de 
controle d'acces. 

Selon une rnise en oeuvre de ('invention, les donnees D representent une 
ou des decisions partielles pouvant prendre une valeur parmi les possibilites 
10 suivantes : 

• Acceptation de I'appel, 

• Rejet de I'appel, 

• Non-decision. 

15 Decisions partielles prises par les modules de controle d'acces 

Selon une mise en oeuvre preferentielle de ('invention, chaque module 
de controle d'acces est a meme de prendre une decision partielle concernant 
chaque appel regu. Cette decision partielle peut etre prise de fagon 
20 independante des autres decisions partielles prises par les autres modules de 
controle d'acces. Cette fagon de faire permet de les rendre independant les 
uns des autres afin de rendre le systeme modulaire. 

Une decision partielle d'acceptation est emise par un module de controle 
d'acces lorsque I'appel doit etre accepte, independamment de la decision des 
25 autres modules de controle d'acces. Par exemple, dans une application de 
I'invention au domaine des telecommunications, un abonne peut vouloir qu'un 
correspondant particulier (par exemple son conjoint) puisse le joindre a tout 
moment. Un tel appel doit done etre accepte. 
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En ce cas, le module de controle d'acces correspondent d un mecanisme 
de type « liste prioritaire » emet une decision de type « Acceptation de I'appel » 
qui signifie qu'il n'est pas necessaire d'interroger les autres modules de 
controle d'acces pour etablir une decision finale d'acceptation. 

5 Une decision de type « rejet de l'appel» est emise par un module de 

controle d'acces lorsqu'un appel doit etre rejete independamment de la 
decision des autres modules de controle d'acces. Par exemple, si un appel 
provenant d'une zone geographique qui fait I'objet d'un filtrage survient, le 
module de controle d'acces mettant en oeuvre le filtrage sur zone 
10 geographique emet une decision de type « rejet de I'appel ». 

Dans tous les autres cas, les modules de controle d'acces emettent des 
decisions de type « non-decision » qui signifient qu'ils ne sont pas a meme ni 
d'accepter I'appel de faqon inconditionnelle, ni de le rejeter. 

C'est par exemple le cas d r un module de controle d'acces mettant un 
15 oeuvre un filtrage sur la zone geographique de I'appelant, et que celui-ci 
n'appartient pas a une zone proscrite, II ne peut alors pas le rejeter, ni 
I'accepter car le fait que I'appel ne soit pas exclu par son filtre ne signifie pas 
qu'il ne soit pas exclu par d'autres filtres mis en oeuvre par d'autres modules 
de controle d'acces. 

20 

Plusieurs mises en oeuvre sont possibles pour organiser les modules de 
controle d'acces et les faire cooperer afin d'arriver a un consensus. 

Organisation en chaTne 

25 

La figure 2 illustre une premiere fa^on d'organiser I'ordonnancement des 
communications entre un module maitre M et I'ensemble des modules de 
controle d'acces A 1; A 2/ A 3 ... A n qui lui sont associes. 
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Selon cette mise en ceuvre, les modules de controie d'acces sont 
organises en chaTne. 

Dans un premier temps, le module maTtre transmet les informations I 
relatives a I'appel au premier module de controie d'acces de la chaTne, A v Si 
5 ce premier module de controie d'acces prend une decision D } de type 
« Acceptation de I'appel » ou « Rejet de I'appel », il la transmet au module 
maTtre. Dans le cas contraire (« non-decision »), il transmet les informations 
relatives a I'appel au second module de controie d'acces de la chaTne, et ainsi 
de suite. 

10 Le dernier module de controie d'acces transmet sa decision D n , quelle 

qu'elle soit, au module maTtre. Ce module maTtre possede des moyens pour 
prendre une decision finale en fonction de la decision qu'il a regue d'un des 
modules de controie d'acces. II est en effet a noter que dans cette mise en 
oeuvre particuliere, il ne peut recevoir qu'une seule decision. 

15 Dans le cas ou la decision regue est de type « Acceptation de I'appel » ou 

« Rejet de I'appel », la decision finale est identique a la decision regue. Dans 
le cas ou la decision est de type « non-decision », alors la decision finale est 
une acceptation de I'appel. 

20 Organisation en etoile 

La figure 3 illustre une autre fagon d'ordonnancer les communications 
entre un module maTtre M et I'ensemble des modules de controie d'acces A u 
A 2/ A 3 ... A n qui lui sont associes. 

25 Selon cette mise en ceuvre, les modules de controie d'acces sont 

organises en etoile, c'est-a-dire qu'ils transmettent leur decision D,, D 2 , D 3 ... 
D n , quelle qu'elle soit, au module maTtre. 
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Une premiere possibilite pour implementer cette mise en oeuvre consiste 
a transmettre les informations relatives a I'appel parallelement a tous les 
modules de controle d'acces. Ceux-ci traitent I'appel de fagon concurrente 
puis transmettent leur decision au module maTtre. 

5 Une seconde possibilite consiste a transmettre les informations relatives 

a I'appel a un premier module de controle d'acces, A w d'attendre sa decision 
pour, eventuellement, transmettre ces informations a un deuxieme module de 
controle d'acces, A 2 , et ainsi de suite. 

Cette seconde mise en oeuvre minimise les echanges entre le module 
10 maTtre et les modules de controle d'acces, mais requiert, sauf cas 
exceptionnellement favorable, davantage de temps de traitement. 

Gestion des conflits 

15 II est possible que certains modules de controle d'acces soient amenes a 

prendre des decisions contradictoires. Par exemple, si un mecanisme d'appel 
prioritaire et un mecanisme de rejet sur creneau horaire sont mis en place, un 
meme appel peut faire I'objet d'une decision de type « Acceptation de I'appel » 
et d'une decision de type « Rejet de I'appel ». 

20 Ce conflit apparent peut etre resolu au moyen de priorite, c'est-a-dire en 

decidant d'un ordre d'importance des decisions prises par les differents 
modules de controle d'acces. 

Dans le cas d'une mise en oeuvre sous forme de chaTne, le rang du 
module de controle d'acces (c'est-a-dire, sa position dans la chaTne) 
25 correspond directement a sa priorite. 

II en est de meme dans le cas d'une mise en oeuvre dans laquelle les 
modules de controle d'acces sont organises en etoile, si le module maTtre 
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transmet les informations relatives a Pappel de fagon sequentielle, c'est-a-dire 
a la suite de la reception d'une decision, comme decrit precedemment. 

Dans ses deux situations, les modules de controle d'acces ayant une 
forte priorite sont a meme de prendre des decisions avant que les modules de 
5 controle d'acces de priorite moindre aient pu etre interroge. Les conflits sont 
ainsi evites. 

Dans le cas d'une mise en oeuvre de type "etoile" dans laquelle les 
informations relatives a Pappei sont transmises de fagon parallele, le module 
maTtre est en mesure de recevoir deux decisions a priori contradictoires. II 
10 convient done d'associer une priorite, par exemple sous la forme d'un nombre, 
d chaque module de controle d'acces, ces priorites pouvant etre stockees dans 
une table contenue par le module maTtre. 

De fagon alternative, il est egalement possible de mettre en oeuvre un 

systeme de vote, e'est-a-dire que le module maTtre compte les nombres de 

15 decisions de type « Acceptation d'appel » et les decisions de type « Rejet de 
I'appel » et prends sa decision finale en fonction de ces nombres. 

Implementation et ajout dynamique de nouveaux modules 

20 Selon une mise en oeuvre de I'invention, les differents modules (rnaTtres 

et de controle d'acces) peuvent etre implementes conformement aux 
specifications CORBA (Common Object Request Broker Architecture) de I'OMG 
(Open Management Group). Dans ce cas, les communications entre les 
differents modules (decisions, informations relatives aux appels...) sont 

25 effectuees par Pintermediaire d'un bus logiciel (appele ORB, pour Object 
Request Broker) auquel les modules sont connectes. 

Une propriete de CORBA est de pouvoir connecter de fagon dynamique 
des nouveaux elements logiciels au bus logiciel et de le faire connaTtre aux 
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elements logiciels precedemment connectes. Ainsi, il devient possible d'ajouter 
dynamiquement des nouveaux modules de controle d'acces sans qu'il soit 
necessaire de recompiler le systeme, ni meme de le stopper. Une telle mise en 
ceuvre de 1'invention, quoi que grandement facilite par I'apport de CORBA ou 
5 d'autres environnements de meme type (tel DCOM de la societe Microsoft), 
est susceptible d'etre realisee quelque soit I'environnement technique sous- 
jacent. 

D'une fagon generale, il suffit que le module maTtre dispose de moyens 
pour recevoir des demandes d'ajout de nouveaux modules de controle 
10 d'acces, et les inclure dans I'ensemble des modules de controle d'acces 
auquel il est associe. 

Les priorites que Ton affecte aux modules de controles d'acces, pour un 
service de telephonie, peuvent etre divisees en plusieurs groupes : 

15 • Un groupe « societe » 

• Un groupe « abonne » 

Ainsi, un abonne peut ajouter de nouveaux modules de controles 
d'acces (par exemple un renvoi d'appel, ou une liste prioritaire) mais ceux-ci 
se verront systematiquement affectes par le systeme une priorite plus faible 
20 que ceux appartenant au groupe « societe ». Ces derniers mettent en ceuvre 
des recommandations globales pour I'ensemble d'un site ou d'une societe. 

Modules de traitement d'appels 

25 Selon une mise en ceuvre de I'invention, le systeme dispose de surcroTt 

d'un ensemble de modules de traitement d'appels, qui ont pour charge de 
realiser correctement I'acces au service demande. 
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Dans le cadre d'une application de I'invention au domaine des 
telecommunications, ces modules de traitement d'appel peuvent mettre en 
ceuvre des algorithmes de routage d'appel au travers d'un reseau jusqu'au 
service ou abonne demande, de taxation de ces appels, etc. Selon cette mise 
5 en ceuvre, une fois qu'un appel a ete accepte, le module maTtre peut 
transmettre des informations relatives a cet appel a un ensemble de modules 
de traitement d'appel afin qu'il soit correctement achemine dans le reseau, 
facture, etc. 

10 Cette mise en oeuvre est illustree par la figure 4. 

A la reception d'un appel, le module maTtre transmet des informations I 
relatives a cet appel vers Pensemble E des modules de controle d'acces, A u A 2 , 
A 3 ... A n . II reqoit ensuite une ou plusieurs decision de la part de cet ensemble 
E A et decide alors de I'acceptation ou du rejet de I'appel concerne ainsi que 
15 precedemment explique. 

Ensuite, le module maTtre peut transmettre des informations l R relatives a 
cet appel vers I'ensemble E R des modules de traitement d'appel, R u R 2/ R 3 -.R P - 
Ces informations l R peuvent etre identiques ou differentes des informations I 
transmises aux modules de controle d'acces. 

20 II peut alors recevoir une ou plusieurs decisions D R de la part de cet 

ensemble et peut eventuellement prendre une decision finale a partir de ces 
decisions. Ces decisions peuvent concerner I'acheminement (ou routage}, la 
taxation, etc. 

25 Determination du modules de traitement d'appel 

Selon une mise en oeuvre de I'invention, les modules de controle d'acces 
emettent, en meme temps qu'une decision de type « acceptation de 1'appel", 
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un identifiant du module de traitement d'appel qu'il decide devoir traiter 
I'appel. En effet, la connaissance des specialisations des differents modules de 
traitements d'appel peut etre deportee sur les modules de controle, afin 
d'accroitre la modularity du systeme. 

5 Toutefois, une autre mise en oeuvre possible consiste en ce que le 

module maitre ait une connaissance a priori des associations entre les 
modules de controle d'acces et les modules de traitement d'appels, c'est-a- 
dire sans qu'il soit necessaire que les premiers transmettent I'identifiant d'un de 
ces derniers. 

10 

En reprenant I'exemple d'un systeme de telecommunication, a chaque 
module de controle d'acces est associe un (ou plusieurs) module de traitement 
d'appel. Pour simplifies on suppose que ces modules de traitement d'appel 
ne sont en charge que du routage des appels. 

15 Lorsqu'un module de controle d'acces prend une decision de type 

« Acceptation de I'appel », il transmet au module maTtre, d'une part ladite 
decision, et d'autre part un identifiant d'un module de traitement d'appel. Le 
module maTtre est alors a merne de dialoguer avec ce dernier, afin de 
determiner le numero d'appel de I'appele. 

20 Par exemple, si un module de controle d'acces gere un filtre de renvoi 

d'appel, alors il peut transmettre une decision de type « Acceptation de 
I'appel » en indiquant quel est le module de traitement d'appel qui est a 
meme d'effectuer le renvoi d'appel en attribuant le bon routage dans le 
reseau. 
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REVENDICATIONS 

1) Systeme pour la gestion d'appels (C) de services, comportant des 
modules de controles d'acces (A, A 2/ A 3 ... A n ) mettant en oeuvre des 
mecanismes de controle d'acces aux services, caracterise en ce qu'il comporte 
en outre des modules maitres, chacun etant associe a un service et a un 
ensemble (E) de modules de controle d'acces et comportant : 

• des moyens pour recevoir lesdits appels, 

• des moyens pour transmettre des informations (I) relatives a 
chacun desdits appels audit ensemble de modules de controle 
d'acces, 

• des moyens pour decider de I'acceptation desdits appels en 
fonction de donnees (D) regues dudit ensemble de modules de 
controle d'acces. 

2) Systeme selon I'une des revendications precedentes, dans lequel 
lesdits modules de controle d'acces possedent des moyens pour emettre des 
decisions (Dr) du type « acceptation de I'appel », « rejet de I'appel » et « non- 
decision ». 

3) Systeme selon la revendication precedente, caracterise en ce que 
lesdits moyens pour emettre des decisions sont prevus de sorte que les 
decisions (D R ) des types « acceptation de I'appel » et « rejet de I'appel » sont 
emises a destination dudit module maTtre. 

4) Systeme selon la revendication precedente, caracterise en ce que 
lesdits moyens pour emettre des decisions sont prevus de sorte que les 
decisions de type « non-decision » sont emises a destination dudit module 
maTtre. 
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5) Systeme selon la revendication 3, dans lequel lesdits modules de 
controle d'acces sont organises en chaTne, lesdits moyens pour emettre des 
decisions du dernier module de controle d'appel de ladite chaTne etant prevus 
pour emettre les decisions a destination dudit module maTtre, et les autre 

5 modules de controle d'acces possedant des moyens pour transmettre lesdites 
informations relatives a I'appel vers les modules de controles d'acces suivants. 

6) Systeme selon I'une des revendications precedentes, dans lequel 
chaque module maTtre possede en outre des moyens pour recevoir des 

10 demandes d'ajout de nouveaux modules de controle d'acces et pour les 
inclure dans I'ensemble des modules de controle d'acces auquel il est associe. 

7) Systeme selon I'une des revendications precedentes, dans lequel 
chacun desdits modules maTtres est de surcroTt associe a un ensemble (E R ) de 

15 modules de traitement d'appel (R,, R 2/ R 3 ... Rp), et possede en outre des 
moyens pour transmettre des secondes informations (l R ) relatives a chacun 
desdits appels, audit ensemble de modules de traitement d'appel, si ledit 
appel a ete accepte. 

20 8) Systeme selon la revendication precedente dans lequel chaque 

module maTtre possede des moyens pour recevoir des demandes d'ajout de 
nouveaux modules de traitement d'appel et pour les inclure dans I'ensemble 
des modules de traitement d'appel auquel il est associe. 

25 9) Procede pour la gestion automatique d'appels a des services, par un 

systeme de traitement de ('information, caracterise en ce qu'il comporte les 
eta pes ordonnees suivantes : 

• reception d'un appel par un module maTtre, 

• transmission par ledit module maTtre, d'informations relatives audit 
30 appel a un ensemble de modules de controle d'acces, 
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• etablissement de decisions par lesdits modules de controle d'acces, a 
partir desdites informations relatives audit appel, 

• transmission d'au moins une desdites decisions, d partir dudit 
ensemble de modules de controle d'acces, vers ledit module maTtre, 

5 • etablissement d'une decision finale par ledit module maTtre, en 

fonction de ladite au moins une decisions. 

10) Procede selon la revendication precedente, comportant en outre une 
etape de transmission de secondes informations relatives a I'appel vers un 

10 ensemble de modules de traitement d'appels, lorsque ledit appel d ete 
accepte. 

11) Procede d'ajout dynamique d'un nouveau module de controle 
d'acces et/ou d'un nouveau module de traitement d'appel, dans un systeme 

15 de gestion d'appel de service, consistant d emettre un message vers ledit 
module maTtre contenant un identificateur dudit nouveau module de controle 
d'acces et/ou dudit nouveau module de traitement d'appel. 
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